Summary

When a tool in the Lucafile is a direct binary download (not an archive) and has binaryPath set to a name different from the tool's name, e.g.:

- name: FirebaseCLI
  binaryPath: firebase
  version: 4.12.1
  url: https://github.com/firebase/firebase-tools/releases/download/v14.12.1/firebase-tools-macos
  ignoreArchCheck: true

…Luca would re-download the binary on every luca install invocation, then fail trying to move the file because it already existed on disk.

Root cause

installExecutable() stored the downloaded file using desiredBinaryName ?? name (resolving to "FirebaseCLI" in this example), but isToolInstalled looked for the binary at binaryPath (resolving to "firebase"). These two never agreed, so the tool was always considered absent.

Fix

Replace the name resolution in installExecutable() with tool.effectiveBinaryPath (desiredBinaryName ?? binaryPath ?? name), which is already the single source of truth used by the rest of the system (SymLinker, PermissionManager, etc).

Type of Change

• Feature
• Bug fix
• Maintenance / Refactor
• Documentation
• CI / Tooling
• Other (specify)

How Has This Been Tested?

Describe the testing strategy and commands executed.

• Added / updated unit tests
• Manually tested locally (describe)
• Tested on macOS (arch: arm64 / x86_64)
• Other

Checklist

• Swift code builds locally (swift build)
• Tests pass locally (swift test)
• Code style / formatting respected
• Documentation updated (README / comments)
• Version / tag alignment considered (if release related)
• PR title follows conventional style (optional)

CI Considerations

• Affects build time notably
• Requires new secrets / env vars
• Alters release process

Breaking Changes?

• No
• Yes (describe impact and migration path)

Additional Notes

Anything else reviewers should know.